【レポート】事例から学ぶ MLOps 実装 Tips(AWS-42) #AWSSummit

AWS Summit Onlineのセッション「事例から学ぶ MLOps 実装 Tips(AWS-42)」の模様をご紹介します。

AWS Summit Online Japan 2022

#レポート

#Amazon SageMaker

#AWS Glue

#AWS Step Functions

#AWS

yoshim

2022.05.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、yoshimです。

本記事は、2022年5月25日(水)に行われたAWS Summit Onlineのセッション「事例から学ぶ MLOps 実装 Tips」のセッションレポートとなります。

こちらのセッションでは「AWSにてMLOpsを実現するためのポイントやアーキテクチャ例」について紹介されていました。

セッション

タイトル:　事例から学ぶ MLOps 実装 Tips(AWS-42)

ビジネスにおける機械学習の活用が進み、機械学習プロジェクトライフサイクル =MLOps の整備に取り組まれるお客様も増えてきました。本セッションでは、Professional Services によるコンサルティング事例を基に、MLOps の概要からアーキテクチャー例、実用的な実装 Tips までご紹介します。 *「添付ファイル」タブで本セッション資料をダウンロードできます。

スピーカー: AWS シニアAI/MLコンサルタント　三輪麻衣子

セッションレベル: Level 400: 上級者向け

MLOpsとは

機械学習のワークロードの特徴として以下3点が挙げられ、これらを手作業でやるのは非効率で情報漏洩につながる可能性がある
- モデル開発時に試行錯誤が必要なため、データ処理を繰り返す
- モデルのデプロイ後も、新しいデータを利用して継続的に改善し続ける必要がある
- 管理対象（ex.利用するデータ、コード、モデル）が多い上、機密度が高いデータを管理しなくてはならないこともある
機械学習システムの「運用性」、「信頼性」、「セキュリティ」、「パフォーマンス」、「コスト効率」を高めるために実施するのが「MLOps」である

MLOpsのポイント

本セッションでは、運用や信頼性を高めるためのポイントとして、「データ」、「モデル」、「インフラ」という3つの切り口から整理する
「データ」は以下3点がポイント
- 加工処理を自動実行できるようにする
- データリネージ（Data lineage）を管理する
- モデル学習に利用したデータを特定できるようにする
「モデル」は以下2点がポイント
- モデルのバージョン、メタデータを管理する
- 推論時の入力、出力、精度を監視し、タイムリーに改善アクションをトリガーできるようにする
「インフラ」は以下3点がポイント
- セキュリティ・コスト要件を満たした状態で環境を標準化し、簡単に構築できるようにしておく
- パフォーマンスを監視する
- 開発〜監視のワークフローを自動化する

「MLOpsのポイント」を実現するために必要なもの

「パイプラインの構築」、「データとモデルを紐づけて管理できる仕組み」、「インフラのテンプレート化」が重要
また、当然ながらそれらを実装・運用するチームは忘れられがちだが非常に重要
- 必要なロールは以下6つ。現実は複数のロールを兼務する人で構成されることが多い
  - データエンジニア
  - データサイエンティスト
  - MLエンジニア
  - MLOpsエンジニア
  - システムアドミニストレーター
  - セキュリティ/コンプライアンスアドミニストレータ

アーキテクチャの考え方

アーキテクチャ検討のステップは以下3ステップ
- 1.要件を明確にする
  - データ関連: データ量、頻度、アクセス制御の粒度、セキュリティ
  - モデル関連: 環境制約、デプロイ方法、承認フロー、改善フロー
  - インフラ関連: 性能要件、可用性、拡張性、自動化範囲、監視対象、運用フロー
- 2.理想系と現状の差分を確認し、ロードマップを描く
  - 完璧でなかろうが、小さく始めて改善していくというアプローチも重要
  - ステージをいくつか分けて考えてみるのも大事
  - ステージ0: 何も整備されていない状態
  - ステージ1: 環境の標準化とテンプレート化
  - ステージ2: データやモデルの管理を統一化しパイプラインを構築
  - ステージ3: イベント発生時に自動的にパイプラインが実行される
- 3.ツールの選定と設計を行う
  - どこにでも適合するベストプラクティスはない
  - 代表的なツールの特性を理解し、自分達の要件に合ったものを選定することが成功への近道

AWSでMLパイプラインを実装する際によく使われるツールと特徴

Amazon SageMaker Pipelines
- メリット
  - SageMaker Studio UIからパイプラインの管理、実行、実行結果の参照ができる
  - キャッシュ機能をONにするとエラー発生箇所のみの再実行が可能
  - SageMaker Projectを利用することで、データ処理、モデルデプロイ、監視の実装まで含めたパイプラインの自動生成が可能
- 要考慮点
  - SageMaker SDKに慣れが必要
AWS Step Functions
- メリット
  - GUIでワークフローを開発・編集できる
  - サーバーレス
- 要考慮点
  - メタデータ管理を作り込む必要がある
  - 部分再実行をするには工夫が必要
  - データとモデルの管理の仕組みは別途考える必要がある
Amazon Managed Workflows for Apache Airflow（MWAA）
- メリット
  - 管理画面への情報集約度が高い
  - データエンジニアやデータサイエンティストが使い慣れているPythonで柔軟に開発できる
  - AWSサービス以外との連携も容易
  - 部分実行が可能
- 要考慮点
  - サーバレスではないので環境起動中ずっと課金されてしまう
  - データとモデルの管理の仕組みは別途考える必要がある
Kubeflow
- メリット
  - AWSサービスと連携することで、OSSの自由度を保ちつつ運用性や拡張性を高めるアプローチを取れる
- 要考慮点
  - 部分再実行ができない
  - コンテナ稼働環境の構築・運用が必要

AWSでMLデータ処理を実装する際によく使われるツールと特徴

Amazon SageMaker Processing
- メリット
  - SageMaker Studio UIからパイプラインの管理、実行、実行結果の参照ができる
  - SageMaker Data Wranglerを使えばGUIで開発できる
  - Sparkコンテナを使えば大規模分散処理も可能
- 要考慮点
  - SageMaker SDKに慣れが必要
Amazon Managed Workflows for Apache Airflow（MWAA）
- メリット
  - ワークフローをMWAAで作成している場合、処理を手軽に組み込める
- 要考慮点
  - サーバレスではないので環境起動中ずっと課金されてしまう
  - 大規模データ（TB単位）の処理には向かない
AWS Glue Job
- メリット
  - GUIで開発できる
  - Sparkで大規模分散処理が可能
- 要考慮点
  - GUIだけで実装できる処理がSageMaker Data Wranglerに比べると少ない
AWS Lambda
- メリット
  - 軽い処理をスピーディーに低コストで実行できる
- 要考慮点
  - 実行時間やメモリ等の制約があるため、大規模（TB単位）の処理には向かない
Kubeflow
- メリット
  - AWSサービスと連携することで、OSSの自由度を保ちつつ運用性や拡張性を高めるアプローチを取れる
- 要考慮点
  - コンテナ稼働環境の構築・運用が必要

アーキテクチャ例1: SageMakerを利用し、迅速簡単に構築できるアーキテクチャ

フローは以下の通り
- データサイエンティストが「AWS CodeCommit」にコードをCommitする
- 「AWS CodeBuild」が「Amazon SageMaker Pipelines」を起動、モデルの学習や後処理までSageMakerで行う
- 学習したモデルを承認者が承認すると、「AWS CodeBuild」が「AWS CloudFormation」スタックを作成し、検証用の「SageMakerの推論エンドポイント」を容易する
- モデルの評価で問題がない場合、承認者が承認することで「AWS CloudFormation」スタックを用いて本番用推論エンドポイントを起動する
- 推論エンドポイントへの入力、出力データは「Amazon SageMaker Model Monitor」で監視し、レイテンシーは「Amazon CloudWatch」で監視する
- どこかで異常が発生した場合、「Amazon SNS」を介して管理者に通知する
やっていることは多いが、ここで記載した内容は「Amazon SageMaker Project」を作成すると自動生成されるリソースが殆どのため、それほど時間をかけずに作成できる
これから実装するという状態から手軽に典型的な基盤を構築したい、AWSサービスに対する学習コストを下げたい、という場合はこのアーキテクチャがマッチする

アーキテクチャ例2: GUIワークフロー + 大規模データ

StepFunctionsとGlueを中心とした、GUIで開発できるワークフロー
フローは以下の通り
- S3にデータがアップロードされることをトリガーにワークフローが実行される
- Glue Jobが前処理
  - 「Amazon SageMaker Processing job」で置き換えることも可能だが、必要な計算リソースとコストのバランスで選択すること
- SageMakerでモデルの学習、後処理、テスト用推論エンドポイント起動
- Lambdaでテストを実施、結果を「Amazon SNS」を介して承認者に通知
- 担当者が承認すると、APIGateway⇨Lambdaと介して、本番用のSageMaker推論エンドポイントが起動
- ここまでで出力されるメタデータはDynamoDBで管理
- 本番用推論エンドポイントへのInput、Outputは「SageMaker Model Monitor」で監視し、推論処理のレイテンシーは「Amazon CloudWatch」で監視する
- どこかで異常が発生した場合、「Amazon SNS」を介して管理者に通知する
「GUIで開発したい」、「StepFunctionsに慣れている」、「処理データ量が多い（TB単位）」といった場合はこのアーキテクチャがマッチする
実装Tips
- メタデータ管理部分を作り込む必要がある
  - DynamoDBで管理することも多いが、データセットとモデルの紐付き管理については「Amazon SageMaker Model Registry」の活用も検討
- 問題発生時に途中からリトライできるようにするためには、StepFunctionsの実装に工夫が必要となる
  - ex.処理実行前に対象処理が既に終了したかを判断する処理を追加する（日時処理等で日付から判断）

アーキテクチャ例3: 柔軟・管理しやすいワークフロー

MWAAとAmazon SageMakerを組み合わせたワークフロー
スケジュール実行、もしくは手動で任意実行するケースを想定
フローは以下の通り
- MWAAで前処理を実行
- Amazon SageMakerでモデルを学習
- MWAAで後処理
- Amazon SageMaker Model Registryにモデルを登録し、テスト用の推論エンドポイントを起動
- MWAAでモデルの評価を実施し、結果をAmazon SNSを介して担当者に通知
- 担当者がその結果を承認すると、APIGateway⇨Lambdaと介して本番用のSageMaker推論エンドポイントが起動
- 本番用推論エンドポイントへのInput、Outputは「SageMaker Model Monitor」で監視し、推論処理のレイテンシーは「Amazon CloudWatch」で監視する
- どこかで異常が発生した場合、「Amazon SNS」を介して管理者に通知する
「アーキテクチャ例1」とは逆に「自分たちで作り込みたい、AWS外リソースと連携させる等の自由度が欲しい」場合に好まれる
Pythonで開発できる、Airflowの知見を活かせる、ワークフロー管理画面に必要な情報を集約できて楽、というメリットもある
- アーキテクチャ例1,2だと様々なAWSサービスの管理画面を参照しないといけないので大変
実装Tips
- サーバレスではないので、環境起動中は利用していない時もコストが発生する点に注意が必要。処理頻度が低い場合は必要時のみ起動してコスト節約する工夫が必要。
  - 環境を削除するとメタデータも消えるのでS3に保存する

セッションのまとめ

MLOpsのアーキテクチャ検討のステップが重要
- 1.要件を明確にする
  - データ、モデル、インフラ、という観点から確認するべきポイントを整理した
- 2.理想系と現状の差分を確認し、ロードマップを描く
  - スキル、既存資産を把握した上で、小さく進めていくことが大事
- 3.ツールの選定と設計を行う
  - AWSで実装する上で代表的なツールのうち、パイプラインとデータ処理に関するツールのメリットや考慮点、アーキテクチャ例と利用時のTipsを紹介した
他にも以下情報が参考になります